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ABSTRACT 


In this report, commonly used lossless and lossy image 
compression algorithms are heuristically presented and then 
compared in terms of performance. The lossy algorithms, JPEG 
(Joint Photographic Experts Group) and Fractal compression, 
are compared in terms of their respective sensitivities 
between compression ratio and image fidelity. Compression 
algorithms based on the lossless models of Huffman, Adaptive 
Huffman, and Arithmetic coding are compared in terms of 
compression ratio and compression/decompression time require- 
ments. High fidelity image reconstructions of JPEG and 
Fractal compressions are also included in the comparison. 
Results, for the images tested, indicate that if imperceptible 
losses in fidelity can be tolerated, then among the current 
versions of the algorithms tested, the JPEG results in higher 


compression with less process time. 
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I. INTRODUCTION 


A. REVIEW OF LITERATURE 

The explosive proliferation of information in recent years 
has created a significant demand for the efficient storage, 
access, and transmission of this data. This is especially 
true for digital images, as an extremely large number of bits 
is required in order to represent even a modestly sized single 
image with acceptable quality and resolution. Image compres- 
sion, which has come into existence only within the last ten 
years, is the area of image processing that deals with this 
problem (Jain, 1981), (Nelson, 1992), (Rabbani, 1991). Its 
goal is to reduce the number of bits used to store or transmit 
the image, yet retain an acceptable quality for the end user. 

A variety of image compression techniques have been 
developed over the years. They have been based on lossless 
and lossy properties. The methods making use of lossless 
properties generate an exact duplicate of the original image 
upon decompression. Lossy methods, on the other hand, 
relinquish some accuracy in exchange for increased compres- 
sion. The efficiency of each of these compression algorithms 
is measured by its compressing ability, distortion or fidelity 


between the original and final decompressed image, and 











computational complexity, which has a direct relation to time 
requirements for implementation (Jain, 1981, p. 349). 


Some of the lossless algorithms that have been developed 


are the Huffman and Adaptive Huffman (Knuth, 1985), (Nelson, 
1992), (Rabbani, 1991), Arithmetic (Langdon, 1984), (Nelson, 
1992), (Rissanen, 1979), (Witten, 1987), and the Ziv and 
Lempel (LZ78) models (Jackson, 1993), (Nelson, 1992). With 


the applications for image processing growing dramatically 
(for instance in satellite imaging, computer graphics in 
advertising and entertainment, and model simulation in science 
and engineering), lossy compression techniques have received 
the most attention in recent years. One widely accepted 
standard is the Joint Photographic Experts Group - Discrete 
Cosine Transform (JPEG-DCT) (Ahmed, 1974), (Ahmed, 1975), 
(Nelson, 1992), (Wallace, 1992). Additionally, a relatively 
new method being explored takes advantage of the fractal 
character for compression of an image. It makes use of 
iterative techniques to exploit the redundancy in images 
(Barnsley, 1993), (Fisher, 1992), (Jacobs, 1992), (NOSC 


TR1315), (NOSC TR1362), (NOSC TR1408). 


B. OVERVIEW OF THE THESIS 
The current chapter introduces the area of image process- 


ing known as image compression. The various methods of image 





compression and the basis for determining the efficiency of 
each are presented. 

Chapter II discusses the models of three accepted lossless 
compression techniques whose efficiencies will be examined. 
Those models discussed for future comparison are the Huffman, 
Adaptive Huffman, and Arithmetic algorithms. 

Chapter III describes the methods of the two lossy 
compression techniques that will be analyzed in this research. 
The lossy routine models presented are the widely utilized 
JPEG-DCT and the relatively new Fractal-based algorithm. 

In Chapter IV, a comparative analysis of the different 
efficiencies of each of the presented image compression 
techniques is performed. The advantages and disadvantages of 
each of the examined methods are discussed. 

The general conclusions reached from the comparative 
analysis of Chapter IV are presented in Chapter V. 

Appendix A covers the operational mechanics which were 
required to gather data for comparison of the different image 
compression techniques. Topics discussed include image 
format, conversion between image formats, display of images, 
and PC versus Sun Workstation operations. Appendix B lists 
some public domain Fractal Compression Code and Appendix C 


contains the numerical data gathered during the research. 














II. LOSSLESS COMPRESSION TECHNIQUES 


A. THE HUFFMAN ALGORITHM 

The basic premise of Huffman coding is the creation of 
variable-length codes for each symbol, with each code being 
represented by an integral number of bits. Symbols with 
higher probabilities are assigned shorter bit codes while 
symbols with lower probabilities are assigned longer pit 
codes. Once the frequency or probability for every symbol in 
a source is determined, the Huffman code can be constructed by 
repeatedly combining the two least probable symbols at each 
ctage until the original source is reduced to only two 
symbols. These two symbols are respectively assigned the bit 
values of ‘0’ and ‘1’. The codes for the previous reduced 
stage are then determined by appending a ‘0’ or ‘i’ to the 
right of the code corresponding to the two least probable 
symbols. The process is repeated until each symbol in the 
original source is assigned a code, thus obtaining the Huffman 
code. Table II.1 shows an example source reduction and Table 
II.2 performs the resulting codeword construction for generat- 
ing the Huffman code. Looking at Table II.2, it can be seen 
that the final codes have the unique prefix property, meaning 
no single code is a prefix for another code. Therefore, they 
can be unambiguously decoded as they arrive in a continuous 


4 











TABLE II.1: EXAMPLE SOURCE REDUCTION PROCESS FOR HUFFMAN 


CODING. 
Original Redu-ed Reduced Reduced 
Source —— a a 


s, Count Prob 









TABLE II.2: EXAMPLE SOURCE CODEWORD CONSTRUCTION PROCESS FOR 
HUFFMAN CODING. 


Original Reduced Reduced Reduced 
Source ee eee ee 


Codeword 


stream. Additionally, the symbol with the highest prob- 


ability, s,, has been assigned the fewest bits while the 
symbol with the lowest probability, s,, has been assigned the 
greatest bits. It should be soted that symbols of equal 
weight can be interchanged to make an equally optimal Huffman 


code. 





Each of the above observations contribute tc make Huffman 
coding fairly simple to implement. 

One of the limitations of Huffman coding is that since the 
number of bits for each code must be an integer, the ideal 
code length for a symbol is met only when its probability is 
a negative power of two, i.e., 1/2, 1/4, 1/8, etc. This is 
because the ideal binary code length for a symbol sg, is 
1(s,)=-log,(p,), where p, is the probability of s,. Therefore, 
the chance of the Huffman code being set to ideal lengths is 
not very likely. The example in Tables II.1 and II.2 accom- 
plishes compression by reducing the average symbol length 


(L.) from 3.0 to 2,0. 


Ly,=), BP, 1(5,) (IT.1) 


iz) 


where n is the number of symbols. The original L,, is 3.0 
because three binary bits are needed to differentiate between 
five symbols. Another limitation is that a copy of the 
probability table must be transmitted with the compiessed data 
Since the expansion program would otherwise not be able to 
decode it correctly. A preset Huffman code could be used to 
avoid this limitation, but then the model is not very adapt- 
able to changing source statistics. In fact, there is even 
the possibility of expansion if the preset code is used with 


changing sources (Rabbani, 1991, pp. 27-28). 











B. ADAPTIVE HUFFMAN ALGORITHM 

In the H~ nan model discussed above, the probability of 
each of the symbols was determined without any consideration 
of the symbols that preceded it. This is known as a zero 
order model. By accounting for predictability, or increasing 
the model order, one may further reduce the number of bits 
required for the data. The trade-off though, is that the 
number of probability tables that must be transmitted with it 
will also increase. In essence, the savings in image data are 
negated by the requirement for additional probahility tables. 

Adaptive Huffman coding allows for the use of higher order 
modeling without the requirement of the added probability 
tables. This is accomplished by adjusting the Huffman codes 
progressively, based only on previous data. Instead of first 
determining probabilities ard then encoding as in the Huffman 
procedure, the Adaptive model initially assumes all symbol 
weights are zero and counts the symbol frequencies as it 
encodes them. After each symbol, the Huffman code is modified 
to account for the new character. The decoding process 
Similarly learns the symbol frequencies and modifies the 
Huffman code in the same fashion. Thus, the encoder and 
decoder remain synchronized because any changes to symbol 
probabilities in the encoder are also taking place in the 
decoder. The only requirement is that both sender and 


receiver know the size of the symbol domain, which is the 
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number of different symbol possibilities (Knuth, 1985, pp. 


163-164). 


C. ARITHMETIC ALGORITHM 

Even though variations of Huffman coding are currently 
accepted to be the most efficient fixed-length lossless coding 
inethods, they still have one major disadvantage. This is the 
requirement that symbol codes be an integral number of bits. 
As stated earlier, this only occurs for probabilities of 1/2, 


1/4, 1/8, etc. If the probability of a symbol is 1/5, the 


optimum code length would be -1log,(0.2) 2.32 bits. Huffman 
code would require two or three bits to encode the symbol, 
thus preventing maximum compression. 

A viable solution to this problem is Arithmetic coding, 
which is another lossless technique that represents the entire 
message aS a number stream. The idea is to represent the 
entire symbol domain as the interval of real numbers between 
zero inclusive and one exclusive ([0, 1)). Each symbol, based 
on its probability, is assigned a range within the interval. 
Table II.3 demonstrates a sample interval range assignment. 

Before encoding is initiated, the range is [0, 1). As 
each symbol is processed, the range is narrowed to that 
interval within the current range which is allocated to the 


symbol. As successive symbols are processed, the interval 


becomes smaller and smaller. The higher the probability of a 














TABLE II.3: EXAMPLE ARITHMETIC CODING RANGE ASSIGNMENT. 


[0.00, 0.40) 
0.40, 0.65 


0.80, 0.90) 
[(O9.63:' 2.00 


symbol, the less it will reduce the range and therefore, add 


(0.40, ) 
[0.80, 
) 





fewer bits to the code. Table II.4 shows the process based on 


the symbol probabilities listed in Table II.3. 


TABLE II.4: ARITHMETIC ENCODING PROCESS. 





The decoding process is then fairly straightforward. The 
first symbol is determined from the subinterval of [0,1) in 
which the encoded message falls. The next symbol is discov- 
ered by subtracting the low value of the first symbol with the 


encoded value and dividing by the width of the range. The 














symbol is then found via the interval in which the new encoded 
value falls. The decoding algorithm for the message "BADACE" 


is illustrated in Table II.5. 


TABLE II.5: ARITHMETIC DECODING PROCESS. 


Encoded Number 
0.48314 poe | oo | o.6s | 0.25 | 
0.33256 -—a__|e.00 | oso | 0.40 





It should be noted that in actual coding, the values of 
the encoded numbers will be represented in binary. See 
Langdon (1984, pp. 136-139) for an example utilizing binary 
values. Decimal values were utilized in the above example to 
assist the reader in understanding the concept (Nelson, 1992, 
p. 128). Since the decoder interprets the encoded number 0.0 
as a symbol (A in Table II.3) in the domain interval, an end 
of message symbol known to both the encoder and decoder is re- 
quired (Witten, 1987, p. 522). 

An example by Nelson (1992, p. 133) provides insight into 
how compression is obtained in Arithmetic coding. Assume a 
stream ’AAAAAAA’ is to be compressed. The probability of Ais 


known to be 0.9 while the end-of-message character has a 
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probability of 0.1. The ranges [0, 0.9) and [0.9, 1.0) are 
assigned to the A and end-of-message characters respectively. 
Table II.6 shows the results. 


TABLE II.6: SAMPLE ARITHMETIC ENCODING TO SHOW COMPRES - 
SION. 


0.4782969 
0.4782969 


One dilemma of Arithmetic coding is that most ~ omputers 





cannot process numbers of the length needed to encoae an 
image. This is corrected by using an incremental transition 
scheme which links the high and low end bits of successive 
numbers in the symbol stream. Another problem is that of loss 
of precision between the high and low values as the range gets 
very small. This can result in the low value being higher 
than the high value and consequently, causing underflow. This 
is eliminated by inserting checks in the process and so 
increased compression is achieved at the expense of increased 
complexity. 
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Arithmetic coding has shown the most promise in compres- 


sion of black and white or two value, one bit per pixel images 
(Langdon, 1984, pp. 140-142), (Langdon, 1981, pp. 863-866). 
Huffman coding as performed in Chapter II.A is unable to 
compress these images due to the integral coding requirement. 
Lossy techniques have also proven unrealistic because a loss 
of quality in decompression can result in the opposite color 
being output, which could drastically degrade the final image 


due to there being only two colors. 
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III. LOSSY COMPRESSION TECHNIQUES 


A. JPEG-DCT ALGORITHM 

With the ongoing advances in digital image technology, it 
was realized quite some time back that the previously men- 
tioned lossless compression techniques were not going to be 
Satisfactory due to the enormous amounts of data required to 
display a digital image. For example, a digitized, single 
image at color television quality requires upwards of one 
million bytes or 8 million bits of data storage. Therefore, 
in 1989, the ISO and CCITT (International Standards Organiza- 
tion/Consultive Committee for International Telephone and 
Telegraph) joined together to form the JPEG committee to set 
an image compression standard (Wallace, 1992, p. xix). Though 
the JPEG standard has not yet been officially published, it is 
near enough to its final stages so that its applications are 
now being widely used in commercial applications. 

The JPEG encoder, its ..del shown in Figure III.1, 
achieves compression with the combination of lossy quantiza- 
tion followed by entropy encoding. In the most common form of 
the JPEG algorithm, the entropy process is carried out by the 
Huffman or Arithmetic methods (Wallace, 1992, p. xxiii). The 
quantization step allows the user to sacrifice quality in 
order to achieve greater compression. For decompression, the 
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JPEG decoder performs the same steps in reverse order, with 
one slight alteration - an IDCT (Inverse Discrete Cosine 


Transform) replaces the DCT process. 


DCT-BASED JPEG ENCODER 





bere tioe 


ENTROPY 


FOCT jeep QUANTIZER es ENCODER Re 


I 





‘ 
arranges 


Tt! 


: 1 
I , 
ae 


‘TABLE - “TABLE 
‘SPECIFICATIONS! SPECIFICATIONS: 





COMPRESSED 
IMAGE 
DATA 








Figure [I.1: DCT-Based Encoder Processing Steps (Wallace, 1992, p. 
Xxi). 


The first of the four main steps for compression is the 
partitioning of the input data into groups of 8x8 pixels in 
preparation for the DCT (Discrete Cosine Transform), which is 


performed in the second step. The reason for the 8x8 grouping 





is that a DCT performed over the entire image would require an 
inordinate number of computations, as can be seen by the 


following equations: 


N-1 N-1 . 
DCTii,)= "Fe OOCOy, Y pireltx,yycost AVE Joos OXY) aur.) 
x20 y=0 
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where: C(i), CY) = boy ij=0, else Cj), CGY) = 1. 
y2 


In the case of the JPEG, N=8. In the decoding portion, the 


IDCT is defined as follows: 


ee eae Qx+lin, ,Qy+bjn 
IDCT(x,y) = —— C(CYDC pores et Seas aS 111.2 
T(x,y) =) » (QCGDCTU,)cos[ aN Jcos[ 7 ) Ir2) 


The justification for choosing 8x8 sized blocks vice 16x16 or 
any other size is that research has shown there is very little 
predictability between pixels spaced more than eight positions 
away (Nelson, 1992, P. 360). 

There are two reasons for the general use of the DCT/IDCT 
versus the DFT/IDFT (Discrete Fourier Transform/Inverse 
Discrete Fourier Transform). See Gonzalez (1987, pp. 65-69) 
for a definition and explanation of the DFT/IDFT. The primary 
reason is that during reconstruction of the individual blocks, 
pixel disparities on opposite sides of the boundaries cause 
the DFT to leave edge artifacts at the boundaries. In an 
image divided into numerous 8x8 blocks, these boundary 
discontinuities would be highly visible and thus, unacceptable 
(Rabbani, 1991, pp. 109-110). As it turns out, it can be 
shown that an N-point DCT can be represented as the real part 
of the 2N-point DFT of a data sequence or pixel set whose 


values at N+1l, N+2, ..., 2N are equal to zero (Bracewell, 
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1986, pp. 17-18). This is equivalent to the 2N-point DFT of 
a sequence in which the pixel values from points [0, N-1] are 
reflected about a vertical axis placed at N and repeated to 
form an even periodic data set. Due to the smoothness of the 
data set at the boundary, upon reconstruction of the image 
there will not be pixel value disparities or edge artifacts at 
the exterior points. For the second argument, there is little 
sense in taking the DFT and then discarding the imaginary 
values while retaining the real values, when the DCT can 
perform the same function in one step with half the computa- 
tions. Despite this solution, some residual edge artifacts 
from the DCT are still known to be generated after quantiza- 
tion (Kollins, 1992, pp. 191-199). 

Upon completing the DCT transformation, the data mist then 
be quantized. Quantization is vital to obtain compression 
because the DCT is a lossless transformation that does not 
actually compress the image data. Instead, it concentrates the 
Majority of the information into a few coefficients in the 
upper left-hand corner of the data block, the importance of 
which will be explained later. 

Quantization achieves the majority of the compression by 
modifying the DCT transformed coefficients into values 
requiring fewer bits to represent. It is accomplished by 
dividing each DCT coefficient by the corresponding quantizing 
value and rounding to the nearest integer. 
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DCTiy) 
Oy) 


Like the data processed by the DCT, the quantization table is 


Quantized Value = INTEGER{ } (1IT.3) 


an 8x8 block, but it is specified by the user, who makes a 
choice based on the desired final image quality. It is 
effective because it forces many of the DCT coefficients to 
truncate to zero. These zero coefficients are not overly 
important to the reconstructed image quality because after the 
DCT transformation, as stated earlier, most of the useful 
information is concentrated in the upper left-hand corner (0,0 
position) of the DCT block. This coefficient is an average 
value of the overall magnitude of the input data and is called 
the DC coefficient. 

Prior to the final step, the quantized values are arranged 
in a zig-zag sequence (see Figure III.2) to organize the data 


so that the zero values are placed in a more efficient 





Figure II.2:  Zig-zag sequencing 
which is performed after quantiza- 
tion. 
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consecutive ordering. With the zero values arranged in this 


continuous fashion, it is possible to achieve further compres- 
sion by using a lossless technique such as Huffman or Arithme- 
tic coding (Wallace, 1992, p. xxiii). In Nelson's (1992) 
Simplified version of the JPEG algorithm, the scheme utilizes 
runlength encoding in place of the more standard choices 
mentioned above. 

Some steps of the JPEG compression technique will now be 
demonstrated in some examples taken from Nelson (1992, pp. 
365-368). In each case, the image is 8x8 pixels and 256 
different grey-scale colors. Figure III.3 shows a sample 
data-bit representation of a non-quantized test image before 
and after processing by the DCT algorithm. 

The values of the DCT output warrants some discussion. 
"Because of the DCT’s application importance and its relation- 
ship to the DFT, many different algorithms by which the DCT 
and IDCT may be approximately computed have been devised." 
(Wallace, 1992, p. xxi). Small variations in implementation 
or precision may cause different output for the same input. 
Additionally, there are varying methods to input and store the 
output data. As seen in Figure III.3, DCT output values can 
be negative, and in the case of the DC coefficient, greatly 
increased in magnitude. Nelson (1992, pp. 364-365) deals with 
this obstacle in the simplest fashion by allowing 11 bits per 
value. He assumes they may vary from -1,024 to 1,023. More 
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Input Pixel Values: 


140 144 147 140 
144 152 140 147 
152 155 136 167 
168 145 156 160 
162 143 156 148 
147 le, 140 155 
136 156 123 167 
148 155 136 155 


Output Pixel Values: 





Figure H1.3: Sample image data before and after process- 
ing by the DCT. 


memory is required than the original eight-bit values, but the 
quantization and entropy compression steps easily offset this 
temporary increase. Rabbini (1951, pp. 114-115) uses only 
eight bits, but stores the data based on a range and its 
difference from previous values. Wallace (1992, p. xx) shifts 
the input to the DCT from [0, (2?-1)] to [-(2°'), (2?'-1)], with 
p=8 in this instance. Each method has its advantages and 
disadvantages based on the complexity of implementation and 


storage requirements - variables every user must consider. 
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As mentioned before, quantization is a user-selected 
variable. In the next example, the quantization table chosen 
can be seen in Figure III.4. The effects of this quantization 
block on a sample DCT transformed image can be seen in Figure 
III.5. By then reordering into the zig-zag sequence previous- 
ly shown in Figure III.2, further compression of the data can 


be accomplished by processing it through a lorsless encoder. 





Figure I1.4: Selected Quantization Table (Nelson, 
1992, p. 367) 


B. FRACTAL COMPRESSION 
1. Conceptual Background 

Another lossy method of compression is based on the 
"self-similarities" or "fractals" inherently present in an 
image. When magnified, a small portion of an image may 
closely resemble a larger portion of the same image. Benoit 
Mandelbrot, considered to be the father of fractal theory, 
demonstrated that random, computer generated fractals could produce 
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Figure II.5: A sample DCT transformed image before and 
after quantization (Nelson, 1992, p. 368) 


realistic representations of clouds, coastlines, trees, etc. 

Because computer-generated fractal images have similar 
patterns on many different scales, relatively little code 
is all that is usually needed to create them. Once 
written to produce the detail on one scale, much the same 
software can be reused in a loop to repeat the image on 
successively larger (or smaller) scales. Thus a remark- 
ably intricate image blossoms from a small, simple piece 
of software (Zorpette, 1988, p. 29). 

In 1988 Barnsley proposed that if high quality images 
could be created from only a few initial parts, then it should 
be possible to reverse the process in order to gain c parable 
compression. With his proposal thcugh, he realized that 
applying the reverse technique to real images, as opposed to 


21 








generating selectively redundant pictures, was going to be a 
substantially more complex procedure. He has since shown that 
recursive iteration x,,,=W(x,) Of an initial image x, under a 
collection W of carefully chosen affine transformations 
converges toward a desired image p, referred to as an "at- 
tractor". The technique is known as an Iterated Function 
System (IFS). Essentially, Barnsley applied the Contraction 
Mapping Theorem to images for the purpose of data compression. 
In general the theorem states if a mapping, W, is in fact 
"Contracting", then iteration of any data set x, under W will 
converge tO a unique point p that remains fixed, i.e. W(p)=p 
(Barnsley, 1993, pp. 70-73). The information represented by 
this attractor can be encoded in the coefficients of the 
associated affine transformations. Figure III.6 demonstrates 
this principle for two different images. Images III.6(a) and 
III.6(b) are reduced by a half and reproduced three times. By 
the third iteration of this transformation, both images show 
definite convergence to the attracting "fixed point" image in 
Figure III.6(c). 
2. An Algorithm for Fractal Compression/Decompression 
The description to follow is based on fundamental 


principles for Fractal compression (Barnsley, 1993), (Fisher, 


'The general affine transformation is a linear transformation followed by a translation. For 
the purpose of Fractal compression the coefficients of the linear transformation are constant 
(Barnsley, 1993, p. 52). 
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Figure II.6: Demonstration of affine transformations 
causing an image to converge to an attractor (Fisher, 1992, 
p. 2). 


1992). A public domain program written in C, which is built 
on these principles (Young, 1992), can be found in 
Appendix B. 

Consider an image of 256x256 pixels with 256 possible 
grey-scale levels. The image is first divided up into non- 
overlapping blocks of 8x8 pixels called ranges. There are a 
total of 1,024 of these ranges. The image is also divided 
into individual domains, which comprise all possible 16x16 
pixel blocks in the image. This comes to 241 times 241, or 
58,081 total domains. For each range, the domains are 
searched for a match that bears a likeness to the portion of 


the image above that range. During this search, the domain 
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square is be flipped and rotated to find the best match. 


Since it is the matching of two squares, there are 8 possibil- 
ities for each domain: rotations of 0, 90, 270, and 360 
degrees and flipping about the vertical, horizontal, and both 
diagonal axes. To account for the area of the domain being 
four times that of the range, a subsample or average of each 
2x2 pixel area is taken for comparison purposes. The point of 
this matching is to find the "best" affine transformation for 


each domain: 


x abo x e 
wy = |c dO y + If (IT.4) 
z | 00s z O 


where s controls the contrast, o controls brightness, and the 
remaining variables a, b, c, d, e and f determine how the 
partitioned domain is mapped to the range. The least-mean- 


squares value is used to determine if a mapping is acceptable. 
R=)° (s-a, + o-by (H1I.5) 
is] 


But first, the range and domain values for the possible 
Mapping are used to calculate the contrast and brightness 


variables. 
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where n is the number of pixels in the domain or range (64 in 
this case), and the a,’s and b's are respectively the domain 
and range cixel values. By substituting the results from 
formulas (III.6) and (III.7) into formula (III.5), a least- 
mean-Squares value will be available for comparison. If this 
value is less than the initial user input, then the mapping is 
acceptable. If it does not meet the specification, the search 
continues on to the next domain transformation, or in the case 
that all eight, potential transformations have been attempted, 
the next domain. If every domain has been searched without 
meeting the least-mean-squares specification, the best 
possible mapping of all domain transformations is selected. 

After a mapping transformation is obtained for all 
1,024 ranges, the information can be encoded. The encoding 
requires 16 bits for the position of the 16x16 pixel domain, 
seven for the brightness, five for the contrast, and three for 


the flip/rotation needed to map the domain to a range. The 
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bit requirements for the contrast and brightness were based on 


the desired accuracy (NOSC TR1408, p. 13). With these bit 
requirements , the original image of 65,536 bytes (256x256x1) 
can be compressed to 3,968 bytes (31/8x1024), which is a 
compression ratio of 16.52:1. Figure III.7 is a flowchart of 
the Fractal compression procedure. 


Decoding is implemented with the following formula: 
p=p'=W(p') = Wp) =,(p) wp) UU... WP) (111.8) 


where p is the original image, p’ is the decompressed or 
transformed image, and W is the combination of individual 
affine transformations w, (see formula III.4) which converges 
to the fixed point image p’. In essence, arbitrary values are 
input to the domain and iteratively processed through the 
transform equation. As the process is repeated, the arbitrary 
domain values progress towards their respective fixed points, 
which together form the approximation p’ of the original image 
Pp. 

The example provided is a rather simple analysis of 
the fractal compression algorithm. There are a number of 
techniques, some implement=d and some proposed, that can 
greatly increase speed and especially, compression (Fisher, 
1992, pp. 16-20), (Barnsley, 1993, pp. 119-171). They include 


varying the size and shape of the range and also classifying 
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Figure I11.7: Flowchart for the Fractal compression procedure. 


the ranges and domains based on possible similarities. In this 
way, the program does not check domains it knows will not 
converge towards a specified range. 

The trade-off for speed and compression depends on 


user requirements. By increasing or making the least-mean- 
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square specification less restrictive, speed and compression 
can be increased, but the quality of the decompressed image is 
reduced. Since arbitrary data is used for the initial 
decompressed image, the final decompressed image is only as 
good as the affine transformation chosen for recursive 
iteration. The affine transformation, in turn, is then only 
as good as the least-mean-square restriction selected by the 


user. 
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IV. COMPARISON OF METHODS 


A. OVERVIEW 

In terms of performance, the lossless and lossy compres- 
sion techniques discussed in Chapters II and III are analyzed 
for compression ratio, fidelity, and compression/decompression 
time requirements. The compression ratio is the original 
image memory size divided by the compressed data memory size. 
The fidelity is a measure of the quality between the original 
image and the reconstructed image. For the purposes of this 
research, the root-mean-square error (rms) is used to evaluate 
the error between the two images (Gonzalez, 1987, pp. 256- 


257} 


N-1 N-1 
1 


Cm == lg(x, y) -£(x,y) [27}'? (IV.1) 
x20 ysx0 


For NxN pixel images, f(x,y) consists of the individual pixel 
values for the original image and g(x,y) consists of the 
individual pixel values for the reconstructed image. 

With the exception of Fractal compression/decompression, 
the programs utilized in the comparison are taken from 
Nelson’s (1992) text. The Fractal compression/decompression 
program, which is not in public domain, is provided for the 
study and is in executable form only (Netrologic, Inc., 1993). 
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The basic principles for these Fractal programs are outlined 
in Fisher’s notes (SIGRAPH, 1992). The public domain compres- 
sion/decompression C language programs in Appendix B (Young, 
1992) are built upon the same principles. It is noted that 
the public domain version in Appendix B, which is not used in 


the comparison, runs significantly slower. 


B. PRESENTATION OF DATA 

Three different images were selected to be processed by 
each of the compression algorithms. These images can be seen 
in Figure. IV.14 Each image is 256x256 pixels with 256 
possible shades of gray. The format used for input into the 
compression programs is raw pixel grey map. In other words, 
eight bits are needed per pixel so as to distinguish between 
the possible grey-scales, which are represented in memory by 
a symbol from the 256 ASCII character set. The data is read 
proceeding from left to right and top to bottom. 

When viewing the reconstructed images after compression 
using lossy techniques, the rms value is somewhat subjective 
with respect to the quality of the original. In this report, 
arbitrary rms limits were assigned based on parameters set by 
the Television Allocations Study Organization (Gonzalez, 1987, 
pp. 257-258). 


* Excellent - An image of extremely high quality, as good as 
you could desire (0 s e,, < 6). 
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Figure IV.1: Original images (a) LENA, (b) 
AEIAL (c) SIGN. 
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* Fine - An image of quality, providing enjoyable viewing. 
Interference is not objectionable (6 s e,, < 9). 


* Passable - An image of acceptable quality. Interference is 
not objectionable (9 s e,, < 12). 


* Marginal - An image of poor quality; you wish you could 


improve it. Interference is somewhat objectionable (12 sx 
Cums < 14). 


ms 


* Inferior - A very poor image, but you could watch it. 
Objectionable interference is definitely present (14 
Se S27), 


* Unusable - An image so bad that you could not watch it 
(LTS x 


In order to provide the reader with an idea as to how this can 
affect image quality, Figure IV.2 shows LENA for an increasing 
rms. 

With the JPEG, rms is controlled by the input of a 
variable called quality factor, which is an integer from 1 to 
25. The quality factor is directly related to the quantiza- 
tion matrix. The upper left-hand value becomes the quality 
factor plus one, and every variable in the next diagonal is 
increased by the quality factor. This increase continues 
through each diagonal. See Figure III.4 for an example of the 
quantization block for an input quality factor of two. A 
rising quality factor causes a corresponding increase in rms, 
consequently the decompressed image fidelity deteriorates. 

The rms for Fractal compression is varied by a user input 
called the error cut. The error cut is the same as the least- 


mean-squares value defined in formula III.5. An additional 
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Figure IV.2: LENA for varying rms values (a) original, (b) 
4.57 (c) 7.04 (d) 9.28 (e) 11.07 (f) 12.99 (g) 14.31 (h) 
16.47 (i) 19.05. 











user input called optimization level is also required. This 
value varies the possible domain shape, size, and location, in 
addition to range/domain classifications; thus speed and 
compression capability can be modified. 

Figures IV.3 and IV.4 show graphically how rms changes 
with varying quality factor inputs for JPEG ani error cut 
inputs for Fractal compression. For high quality images (low 
quality factor and error cut values), a change in the quality 
factor or error cut has a much more noticeable effect on rms. 
As image quality degrades though, changes in the two variables 
have less of an impact on the resulting rms. One exception is 
the Fractal compression of SIGN. At a certain point, the 
routine is unable to improve rms. Later graphs will also show 
that the compression ratio reaches a limit as well. 

Figure IV.5 is a comparison of rms versus compression 
ratio using the JPEG algorithm. For the most part, there is 
a linear relationship between the two properties. Looking at 
Figure IV.6, at least for processing of LENA and AERIAL, this 
is not the case with Fractal compression. There is a super- 
linear relationship at the very least. At high quality recon- 
struction, a small increase in compression can cause a large 
drop in fidelity. On the other hand, at inferior qualities, 
compression may be drastically increased for only a small loss 
in fidelity. Again, SIGN is the exception because there is 
a linear relationship between the two properties until a point 
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Figure IV.3: Comparison of root-mean-square to quality 
factor for JPEG compression. 


35 





SIGN AERIAL 
£0 














LENA 


FRACTAL 





INO dYOuss 





Figure IV.4: Comparison of root-mean-square to error cut 
for Fractal compression. 
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Figure IV.5: Comparison of root-mean-square to compression 
ratio for JPEG compression. 
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Figure IV.6: Comparison of root-mean-square to compression 
ratio for Fractal compression. 
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where compression reaches a limit. Additionally, the rms 
never gets better than unusable. In actuality, the image is 
discernible, but there is a great deal of distortion or loss 
of distinct boundary between the white letters and black back- 
ground; thus its use for commercial applications in this 
instance is questionable. This boundary ripple is also 
evident with JPEG compression/decompression, even at low rms. 

Figure IV.7 demonstrates when using JPEG compression at 
high fidelity, significant savings can be achieved in compres- 
Sion/decompression time with small drops in image recon- 
struction quality. The reverse is true at poor quality - the 
compression/decompression time reaches a point where reducing 
the fidelity does not result in any savings in time, thus the 
only benefit is decreased data storage requirements. 

A comparison of the compression/decompression time versus 
the compression ratio for each method, applied to all three 
sample images, can be seen in Figure IV.8. The results are 
based on the best obtained rms in the case of the JPEG and 
Fractal routines. It should be noted that since the Huffman, 
Adaptive Huffman, and Arithmetic compression methods are 
lossless, the rms of the decompressed image is zero in each 
cage. Due to vast differences in time for the Fractal 
routines, compression/decompression time is represented by 
taking its log base 10. For LENA and AERIAL, the Fractal 


technique achieves greater compression, but at the expense of 
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Figure IV.7: Comparison of root-mean-square to compres- 
sion/decompression time for JPEG compression of LENA. 
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Figure IV.8(a): For each compression technique being 
performed on LENA, a comparison of compres - 
sion/decompression time to compression ratio. 
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Figure IV.8(b): For each compression technique being 
performed on AERIAL, a comparison of compres - 
sion/decompression time to compression ratio. 
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Figure IV.8(c): For each compression “technique being 
performed on SIGN, a comparison of compres - 
sion/decompression time to compression ratio. 
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a large increase in time. In the case of SIGN, the arithmetic 
and Fractal methods are comparable in compression, with 
arithmetic coding being somewhat better. Arithmetic coding 
though, is able to achieve the reduction in much less time. 
Moreover, its decompressed image does not have the ripple at 
the boundary between the black and white colors. One addi- 
tional note refers to Chapter II.C, which states that black 
and white (one bit per pixel) images could not be compressed 
using Huffman coding. In the case of SIGN however, compres- 
sion is in fact achieved. The reason is that in this case the 
two colors are each represented by eight-bits, not one bit, 
hence a reduction in the data-bit representation is possible. 
The numerical data results for the figures are contained in 


Appendix C. 
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Vv. CONCLUSIONS 


An analysis of the results from the previous chapter indi- 
cates that for multi-color, real world images. the JPEG 
compression algorithm is currently the best method for image 
compression. Though the Fractal method is able to achieve a 
much higher compression ratio for similar rms values, its 
present execution time and computing power requirements 
(Gershanoff, 1988, p. 47), (Barnsley, 1988, p. 222) severely 
limit its practicality for present applications. In its 
defense, the theory and principles behind Fractal image 
compression are still relatively young. As new methods are 
discovered to classify and partition the domain set and find 
the affine transformations needed to map the domain to the 
attractor (range), this technique will only improve. The 
continual advancement in computer processing capability will 
also assist. For these reasons, Fractal compression offers 
the most potential for future applications, such as high 
definition television (HDTV) and image recognition for 
satellite imagery. 

Another advantage of Fractal over JPEG compression is that 
image size can be changed during decompression since any 
scaling is multiplied proportionally through the affine 
transformation at each iteration (Anson, 1991, p. 43). The 
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JPEG is further limited in the image size it can process. The 


8x8 block division criterion reduces possible dimensions to 
those divisible by eight on each side. This 8x8 rule can be 
modified, but then the model does not meet JPEG standards. 

In the case of SIGN - a highly redundant, two color 
image - the lossless method of Arithmetic coding is easily the 
preferred technique. The JPEG and Fractal algorithms are not 
very effective because even at high quality, there is a 
noticeable ripple introduced at the boundary between the white 
letters and black background. Huffman and Adaptive Huffman 
coding are also better methods, considering the compres- 
sion/decompression time, compression obtained, and decom- 
pressed image resolution. Therefore, when compressing two- 
color images (black and white), lossless algorithms are 
certainly the favored procedure since the introduction of 
errors can seriously flaw the decompressed image. 

Future areas of research might introduce other proven 
image compression techniques into the comparison. These 
include higher order Arithmetic coding and the Ziv and Lempel 
(LZ78) dictionary based schemes. The speed-up of the Fractal 
compression routine by altering range/domain classifications 
and domain partitioning, or modifying the methods used to find 
the affine transformations, is another prospect. A third 
concept is the optimization of image compression with a 
combination of two or more of the possible algorithms. The 
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JPEG method, which combines quantization with lossless entropy 
compression, is an example of a two part compression process. 
With the continuing demand for image data though, more 
efficient methods of compression will need to be discovered, 
and the combining of more than one technique is a distinct 


possibility. 











APPENDIX A - OPERATIONAL MECHANICS 


A. CONCERNS 

The inclusion of this appendix is to assist anyone who may 
desire to continue research in the area of image compression. 
The difficulties experienced in getting the compression 
algorithms to run will be discussed. It is anticipated that 
the reader, if deciding to explore this subject area further, 
will obtain a fundamental understanding of the operational 
mechanics and thus, avoid the steep learning curve usually 


associated with new software. 


B. SPECIFIC DIFFICULTIES 

A detailed list of the specific hurdles encountered during 
the research and how each one was approached. 

1. Image Format 

The first area of difficulty deals with image format. 

There are a wealth of possibilities. The documentation 
provided with the Graphics Transformer (IMSI, 1990) is a good 
reference for explaining the differences between various 
format types. For this work, as stated earlier, the format is 
raw pixel grey-map (*.rpg, *.rpgm, or *.raw). In truth, this 
is the closest thing possible to a "non-format". Data is 


listed from left to right, row by row. Each ASCII character 
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represents one of 256 shades of gra y. While worki.ig with the 
images though, one will likely become familiar with many 
additional format types. Raster (*.ras) is utilized for 


working in a Sun System image processing tool called Sun- 


vision. This format is structured with controlling data 
placed throughcut the image data. Each well-known word 
processing package utilizes its own format - (*.wpg) for 


WordPerfect, (*.pic) for Lotus 1-2-3, (*.pcx) for PC Paint- 
brush, (*.dxf) for AutoCAD, etc. Many of the packages are 
able to import files stored in another format, but its 
reference should be checked if unsure. 
2. Sun System to PC & PC to Sun System 

If the image data is not in the required format for 
processing, the Sun System provides a conversion tool called 
imconv. It will convert approximately 30 different image 
format types. It can be accessed by setting a path toc 
/tools2/imagecv/bin/. To see the reference for its execution, 
type imconv -fullhelp at the cursor. Also available for 
format conversion, are numerous PC software packages. One 
utilized by this author is Graphics Transformer (IMSI, 1990). 
Imconv was faster though, and offered many more options than 
its PC counterpart. The image files are transferred from 
floppy disc to Sun account, and vice versa, with mtools. 


Documentation can be obtained in Sp-301. 
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3. Display 

There are several alternatives for image display. The 
Sun System in the Electrical and Computer Engineering (ECE) 
Department offers Sunvision. It can be found in the path 
tools2/sunvision_1.1/bin/. Reference documentation is 
maintained in the ECE image Processing Lab in Sp-546. This 
software is somewhat outdated, thus there are obstacles to 
getting it operational under the current Sun System Windows 
Version 3 (OW3). It can be used only in Open Windows Version 
2 (OQW2). The best advice is to ask the account manager in 
Sp-301 to provide two personal accounts, one that logs in 
under OW2, and another which logs in under OW3. In this 
fashion, Sunvision is accessible and the upgraded capabilities 
of the newer windows is still available. While in account #1, 
a file can be moved from account #1 to account #2 by using the 
cp command. First transfer it to the /temp directory, change 
its accessibility to read/write using the chmod command, and 
after a remote log in to account #2, move the file from /temp 
to account #2. Be aware that all Sun terminals are not 
capable of running OW2. A second Sun option is to write a 
display program. For a beyinning C programmer, this would not 
be overly difficult since the Sun graphics are fairly user 
friendly. 

Another graphics tool is the xv editor on the Silicon 
Graphics machines in the Visualization Lab, In-148. Reference 
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documentation can be acquired by typing man xv at the terminal 
cursor. Besides display, both options offer scaling, rota- 
tion, color altering, and more. This prcevides the flexibility 
to change the image for varying research goals. 

Display is more difficult on the PC because there are 
a vast assortment of video card drivers, a component needed 
for graphics display. Additionally, PC monitors are not as 
capable as Sun monitors; thus a C language display program is 
much more entailed than that needed for Sun monitor display. 
One suggestion is to check if the supplier of the image 
processing software has a display program available. for this 
study, Netrologics (1993) provided a display program called 
rawview. exe. 

4. Printing 

An image printout can be obtained on the Sun by first 
converting the file into postscript (*.ps) format and then 
typing lpr<printer#> <filename>. Another option is to import 
the image into a word processing package. Of course, the file 
will need to be in a format that is readable to the package 
utilized. In terms of size and page layout, this author found 
FrameMaker (available on the Sun) to be very flexible with 


imported files. It requires them to be in Raster format. 








5. Access 


a. Fractal Program 
The Fractal compression/decompression programs in 
Appendix B can be found under the public access address lyapu- 
nov.ucsd.edu. Transfer the files to a personal Sun account 
using the ftp command. Type man ftp at the prompt for 
instructions on the use of this command. After gaining access 
to the public access network, type in anonymous when asked for 
user name, and personal e-mail address when asked for pass- 
word. The programs are listed in the directory /pub/young- 
fractal as unifsl0.tar.Z. This is a compressed archive file. 
To get the individual files, become familiar with the tar and 
compress commands (type man tar and man compress at the 
prompt) . 
b. Nelson’s Compression Routines 
The computer programs listed in Nelson’s book can 
be purchased by calling the publisher (which recently changed 
to Henry Holt Publishing) at 1-800-488-5233. 
ec. Compilers 
The compiler for the Appendix B Fractal programs 
can be obtained on the public access network at omni- 
gate.clarkson.edu, which can be accessed in the same fashion 
described earlier. The directory is pub/msdos/djgpp. The 
required files are djdev109.zip, djgas138.zip, djgcc222.zip, 
djlgri1i1C.zip, and readme.ist. The readme.lst and readme files 
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provide all the instructions for installing the compiler onto 
a PC. One thing not mentioned is that the libgr.a file in 
ajlgrl09.zip needs to be added to the library directory once 
the compiler is installed. 

Nelson’s programs can be compiled using Borland 
C++ 2.0 for MS-DOS (1992, pp. 5-6, 78-79). Since version 2.0 
is obsolete, version 3.0 was found to compile with one excep- 
tion to the example command line on page 79. The -Ax option 
no longer exists, the replacement is just -A. The programs 
will not compile under the Borland MS-WINDOWS version. They 
will also not compile using the cc compiler on the Sun System. 
This requires such significant proyram modifications that they 
must practically be rewritten. 

d. Utilities 

The account manager must set up a Sun account for 
access to FrameMaker, Sunvision, etc. Be sure to specify the 
utilities needed when signing up for an account. 

PC utilities (Borland C++ compiler, PaintBrush, 
WordPerfect, DrawPerfect, etc.) are installed on the computers 
in Sp-431. Reference documentation, if not available, can 
usually be obtained from the lab technician. 

6. Compiling and Running 
a. Fractal Routine on a PC 
Upon installing the compiler as per paragraph 5.c 


above, the program fracpack.c for instance, can be compiled 
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using the command line gcc fracpack.c -lgr -lm -o fracpack. 


The order of the library options (-lgr and -lm) is important 
because the linking is order-sensitive. The program  wdy- 
usual.c in appendix B must be in the same directory as 
fracpack.c because it is called to classify the domains and 
ranges. The compiled file must then be appended to the file 
go32.exe (a program which provides graphics driver interface) 
using a program called aout2exe.exe. Both files are contained 
in the compressed unifs10.tar.Z file. Typing aoutzexe 
fracpack will create a file that is PC executable. 

Since the programs fracpack.c and unifs.c display the 
image during execution, the graphics driver used by go32.exe 
must be set by the user. Directions are listed in the readme 
and document (*.doc) files, which are also included in 
unifsl0.tar.Z. If the proper driver is not set, the computer 
will lockup. 

b. Fractal Routine on the Sun System 

As they are listed in Appendix B, the Fractal 
compression/decompression programs will not run on the Sun 
System. The graphics are not compatible. The programs can be 
modified by removing any code dealing with the display of the 
file. The programs can then be made Sun executable by compil- 
ing with the cc compiler (type man cc). In this case, 
appending to the program go32.exe is not required since PC 
monitor display is not being used. 
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c. Nelson’s Programs on a PC 
With the proper compiler, Nelsons’s programs run 
with no problems. The user should be informed that the 
programs were written for images of 320x200 pixels (1992, pp. 
374), therefore some modifications might be necessary in the 


code in order to process images with different dimensions. 




















APPENDIX B 


This is the file "copying.wy". 
Copyright Information for sources and executables that 
are marked Copyright (C) WD Young 
P.O. Box 632871 
Nacogdoches TX 75963-2871 


This document is Copyright (C) WD Young and may be 


distribute verbatim, but changing it is not allowed. 


Source code copyright WD Young is distributed under the 
terms of the GNU Public License, with the following 


exceptions: 


*Donations are always appreciated. 


A copy of the file "COPYING" is included with this 
document. If you did not receive a copy of "COPYING", 
you may obtain one from whence this document was ob- 
tained, or by writing: 

Free Software Foundation 

675 Mass Ave 


Cambridge, MA 02139 
USA 
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[tee KEe 


kekkkkkk 


#include 
#include 
#include 
#include 
#include 
#define 
#define 
#define 
#define 
#define 
#define 
#define 


wkeKKKKKEKKKKKEKKKKKKKEKKAaAKKE KKK KKKAEKKEKKa KKK KKK KEKE KEKEKE KEKE 


FRACPACK - a program for 
FRACTAL IMAGE COMPRESSION 
image.krd ==> image.ifs 
version 1.0 
kee keke etek kek kee kkk keke kaka eke aKa / 
<stdio.h> 
<stdlib.h> 
<graphics.h> 
<math.h> 
<time.h> 
xsize 256 
ysize 256 
number flips 8 
levels 2 
max_patch 8 
min_patch 4 
max_scale 1.2 


long int usual 
int mapping; 
int main(int argc, char **argv) 
{ /* begin main block */ 

PILE *in, *out, *cf; 

char *inf, *outf, rmsstr[13]; 

unsigned char Image[ysize] (xsize], blurfysize-1} [xsize-1], plotdx, plotdy; 

unsigned char Range [number flips] [max_patch] [max_patch], Domain[max_patch] [m 

unsigned char DX[{xsize*ysize], DY[xsize*ysize] ; 

int reverse; 

long int Domain_Class[levels} [ysize - min_patch + 1] [xsize - min_patch + 1] [ 

long int Range_Class [levels] [max_patch] [max_patch] [2]; 

int i, rx, ry, dx, dy, x, y, besti, bestdx, bestdy, patchsize; 

long int classi, class2, class3, class4, count; 

int inlevel; 

int I[8] [8] es ee 

47,6; 5091; 2, 394,451 491767300 rly 

short int offset, best_offset; 

long int sumr, sumd, sumrd, sumr_sq, sumd_sq; 

long int Domain_sums[2] [xsize - min_patch + 1] [ysize - min_patch + 1]; 

float fsumr, fsumd, fsumrd, fsumr_sq, fsumd_sq, fmagica; 

float best_scale, scale, root_mean_sq, best_root_mean_sq; 

float mean_sq, root_mean_sq_ tolerance, mean_sq_tolerance, best_mean_sq, fpat 

float temp, variance; 

time_t start_time, finish_time; 

long time_used; 


(unsigned char Image(8][(8], int size); 


at 


struct header_t { /* "should" be a 12 byte header... we'll see */ 
long time; /* 4 bytes for compression time in seconds */ 
short rms; /* 2 bytes for 100.*rms value */ 
short addl; /* 2 bytes to be added later... room for growth */ 
long add2; /* 4 bytes to be added later... room for growth */ 
} header [1]; 

struct ifs _t { 
unsigned char dx; 
unsigned char dy; 
signed char scale; 
short int offset 12; 
unsigned short int flip 33 
unsigned short int size i; 


} ifs[1], 








ifs_table[leve].s] [xsize/min_patch] [ysize/min_patch] ; 


if (arge < 4) { 
printf ("usage: fracpack rms infile.ext outfile.ext \n\n"); 
printf ("FRACPACK Version 1.0, Copyright (C) 1992, WD Young\n"); 
printf ("FRACPACK comes with ABSOLUTELY NO WARRANTY\n") ; 
printf ("Please see files ‘copying.wy’ and ‘copying’ for details\n"); 
printf("If£f these files are missing, \n"); 
printf ("write: WD Young, P.O. Box 632871, Nacogdoches TX 75963-2871\n"); 
return 1; 


root_mean_sq_ tolerance = atof(argv[1]}); 


header[0].rms = (short) (100.*root_mean_sq_ tolerance) ; 

inf = argv[Z]; outf = argv([3]; 

if ((in = fopen(inf, "rb")) == NULL) { 
fprintf(stderr, "Cannot open input file.\n"); 
return 1; 

if ((out = fopen(outf, "wb")) == NULL) { 


forintf (stderr, "Cannot open output file.\n"); 
return 1; 


fclose(out); 


start_time = time(start_time) ; 
mean_sq_tolerance = root_mean_sq_tolerance*root_mean_sq_ tolerance; 


GrSetMode (GR_default_graphics) ; 

for (x = 0; x < 64; x+t+) 
GrSetColor(x,4*x,4*x,4*x) ; 

for (x = 64;x < 256; x++) 
GrSetColor(x,x,0,0); 


/* Get .KRD bitmap 8-bit-grey-scale pixels, put in Image array. */ 
for (y = 0; y < ysize; y++) 
for (x = 0; x < xsize; x++) { 
Image [ly] [x] = fgetc(in); 
GrPlot (x,y, Image [y] [x] >>2) ; 
GrPlot (x+300,y, Image [y] [x] >>2) ; 


for (y = 0; y < ysize - 1; y++) 
for (x = 0; x < xsize - 1; x++) 
blur[y] [x] = (Imagel[y ]{x ] 
+ Imagely ] [x+1] 
+ Image[y+1] [x ] 
+ Image [y+1] [x+1] ) >>2; 


fclose(in); 

sprintf (rmsstr, "%4.1f£",sqrt ((double)mean_sq_ tolerance) ); 
GrTextXY (20,290, "rms tolerance", 255, 0); 

GrText XY (130,290, rmsstr,255,0); 


[BR Ra a a He aH Te TT I TTT KT TTT TTT RR TTT EEE EEE RE EEE EE KEK ER RE / 


/* Classify Range’s * / 








[REAR EARTEREHKERKKKRAA KE AAAERAAAaEaaAKAA a eAKAKaAe  / 


inlevel 


ry < ysize; ry+=8) { 
e(0, ry, 255, ry, 384); 
rx = 0; rx < xsize; rx+=8) 


for (y = 0; y < 8; y++) 
for (x = 0; x < 8; x++) 
Range([0) [y] [x] = Image [ ry +y ] [ rx +x ]; 
classl = usual(Range[0], 8); 
Range_Class[inlevel)] [ry>>3] [rx>>3] [0] 
Range_ Class [inlevel] {ry>>3] [rx>>3] [1] 


classi; 
mapping; 


GrLine(0, ry, 255, ry, 384); 


/* 


REE KEKE KEKE KKK EKEKKEKEKKEKKKEKKKKKKKKKKKKKEKKKKKKKK KKK KEKE KKEKEK 


* 


* 


* Compute Domain_sums array * 


* 


* 


RHEE KK KKK KEKE KEKE KKKKKKKEKKKKKEKKKKKKKEKKKKKKK KKK 


ay 
inlevel = 1; 
patchsize = min_patch; 
for (dy = 0; dy < ysize - 2*patchsizet+l; dy++) { 


GrLine(300, dy, 555, dy, 384); 


for 


(dx = 0; dx < xsize - 2*patchsize+1; dx++) 

Domain_sums [0] [dy] [dx] = Domain_sums [1] [dy] [dx] = 0; 

for (y = 0; y < 2*patchsize; y+=2) 

for (x = 0; x < 2*patchsize; x+=2) 
Domain [y>>1] {x>>1] = blur(dy+y] (dx+x] ; 
Domain_sums [0] [dy] [dx] += Domain [y>>1] [x>>1]; 
Domain_sums [1] [dy] [dx] += Domain[y>>1] [x>>1] *Domain[y>>1] [x>>1]; 


variance = (Domain_sums [1] [dy] [dx] - Domain_sums [0] [dy] [dx] *Domain_su 
if (variance > 16) 
class1l = usual (Domain, 4); 
Domain_Class [inlevel] [dy] [dx] [0] [0] 
Domain Class [inlevel] [dy] [dx] [0] [1] 


classl1; 
mapping; 


for (y O; y < 2*patchsize; y+=2) 
for (x 0; x < 2*patchsize; x+=2) 

Domain[y>>1] [x>>1] = 255 - blur[dy+y] [dx+x]; 
class1l = usual(Domain, 4); 
Domain_Class [inlevel] [dy] [dx] [J] [0] = class1l; 


Domain_Class [inlevel] (dy] (dx] [1] (1] mapping; 
else Domain_Class [inlevel] [dy] [dx] [0] [0] = 
Domain_Class [inlevel] [dy] [dx] [1] [0] =-1; 


GrLine(300, dy, 555, dy, 384); 


[kkk ticok tick iicickcinkiciiicicik ict kit bik kk kit / 


/* 


Classify Range’s */ 


[He He HK IK IK IT RK I TK TTT KI TK IT TKK EET EEE EKER ERE KEE EEE KEE KEE RI / 


for (ry 


= 0; ry < ysize; ry+=4) { 


GrLine(0, ry, 255, ry, 384); 














for (rx = 0; rx < xsize; rx+=4) 


for (y = 0; y < 4; yr) 
for (x = 0; x < 4; x+t+) 
Range[0] [y] [x] = Image [ ry +y ] [ rx +x]; 
classl = usual(Range[0], 4); 
Range_Class[inlevel] [ry>>2] [rx>>2] [0] = classi; 
Range_Class[inlevel] [ry>>2] [rx>>2] [1] = mapping; 
GrLine(0, ry, 255, ry, 384); 
/* 
WHERE KKEKKEMEKEKEKKEKKEKEKKEKKEKKEKKEKKEKK KEK KEKE KKEKKKKKKKKKEKKKKEKEKKKKEKKEK 
* * 
* Compute Domain_sums array * 
* * 


HHH KH KH KKH KK KKH KEKE KK KKK KEKE KEKKKKEKKKEKEKEKEKKKKKKKKEKKKEKKEKKKKKKEK 
*/ 
patchsize = max_patch; 
inlevel = 0; 
for (dy = 0; dy < ysize - 2*patchsize+1; dy++) { 
GrLine (300, dy, 555, dy, 384); 
for (dx = 0; dx < xsize - 2*patchsize+1; dx++) { 
sumd = sumd_sq = 0; 
for (y = 0; y < 2*patchsize; y+=2*min_patch) 
for (x = 0; x < 2*patchsize; x+=2*min_patch) { 
sumd += Domain_sums[0] [dy + y] [dx + x]; 
sumd_sq += Domain_sums[1] [dy + y] [dx + x]; 


variance = (sumd_sq - sumd*sumd/63.)/64.; 
if (variance > 16) 
for (y = 0; y < 2*patchsize; y+=2) 
for (x = 0; x < 2*patchsize; x+=2) 
Domain[y>>1] [x>>1] = blur([dy+y] (dx+x] ; 


classl = usual (Domain, 8); 
Domain_Class [inlevel] [dy] [dx] [0] [0] 
Domain_Class [inlevel] [dy] [dx] [0] [1] 


classl; 
mapping; 


for (y = 0; y < 2*patchsize; y+=2) 
for (x = 0; x < 2*patchsize; x+=2) 
Domain[y>>1] [x>>1] = 255 - blur[dy+y] [dx+x] ; 


classl = usual(Domain, 8); 


Domain_Class [inlevel] [dy] [dx] {1] [0] = class1; 
Domain_Class [inlevel] [dy] [dx] [1] [1] = mapping; 
else Domain_Class [inlevel] [dy] [dx] [0] [0] = 
Domain_Class [inlevel] [dy] (dx] [1] [0] =-1; 
GrLine (300, dy, 555, dy, 384); 
/* 
KKK KKK KEK KKK KKK KEKE KK EEK EEK KK EEK KKKEKEKEEKEKKEKEKEKKEKKKKKKKKKEKKK 
* x 
* Range Loop 7 
* * 


HHH KKK KKK KKK KKK KEE KKK KEK KEKE KEKE KEE KKEEKEKEKEEKKKKKKEKKKEKKKKKEK 





inlevel = 0; 

for (patchsize = max_patch; patchsize >= min_patch; patchsize/=2, inlevel++) 
for (ry 0; ry < ysize - patchsize + 1; ry+=patchsize) 

for (rx = 0; rx < xsize - patchsize + 1; rx+=patchsize) { 


GrLine(rx, ry, rx, ry + patchsize, 384); 
GrLine(rx, ry ,xx + patchsize, ry, 384); 
GrLine(rx + patchsize, ry, rx + patchsize, ry + patchsize, 384); 
GrLine(rx, ry + patchsize, rx + patchsize, ry + patchsize, 384); 


sumr = sumr_sq = 0; 
for (y = 0; y < patchsize; y++) 
for (x = 0; xX < patchsize; x++) 


Range [0] [y] [x] =Image [ry +y) [rx +x] ; 
Range [1] [y] [x] =Image [ry+patchsize -1 -x] [rx +y]; 
Range [2] [y] [x] =Image [ry+patchsize -1 -y] [rx+patchsize -1 -x]; 
Range [3] [y] [x] =Image [ry +x] [rx+patchsize -1 -y]; 
Range [4] {y] [x] =Image [ry+patchsize -1 -y] [rx +x] ; 
Range[5] [y] [x] =Image [ry+patchsize -1 -x] [rx+patchsize -1 -y]; 
Range(6) fy) [x] =Image [ry +y) [rx+patchsize -1 -x]; 
Range([7] [y] [x] =Image [ry +x) [rx +y]; 


sumr+=Range [0] [y] [x]; sumr_sq+=Range [0] [y] [x] *Range[0] [y] [x]; 
fsumr=sumr; fsumr_sq=sumr_sq; 


* 
HK KKK KKK REE KKK KKK KEKE KKK KEKE KEKKEKEKEKKEKKEKKEKKEKKKKKKKKKKEEK 
‘ * 
Domain Loop * 
* 
HR HH KKH KKK KEK KKK KKK KKK KEK KKK KEKE KKEEKEKKEKEKKKEKKKEKKKKKKEKEK 


is 
if ((patchsize < max_patch) && 
(ifs_table[inlevel-1)} [ry/(2*patchsize) ] {rx/(2*patchsize)].offset != 
best_mean_sq = 10000000000.; 
count = 0; 
for (dy = 0; dy < ysize - 2*patchsize+1; dy++) { 
for (dx = 0; dx < xsize - 2*patchsize+1; dx++) 


if ((reverse = (Domain_Class[inlevel] [dy] [dx] [0] [0] == Range_Class[i 
(Domain_Class [inlevel] [dy] [dx] [1] [0] == Range_Class[inlevel] [ry/ 
(dy == ry)) 


GrPlot (dx+300+(patchsize>>1) ,dy+(patchsize>>1) , 384); 
DX(count] = dx; DY[{count] = dy; 


count++; 

reverse = 1 - reverse; 

for (y = 0; y < (2*patchsize); y+=2) 

for (x = 0; x < (2*patchsize); x+=2) 
Domain[y>>1] [x>>1] = blur[dy+y ][dx+x ]; 


sumd = sumd_sq = 0; 

for (y = 0; y < 2*patchsize; y+=2*min_patch) 

for (x = 0; x < 2*patchsize; x+=2*min_patch) { 
sumd += Domain_sums[0] [dy + y] [dx + x]; 
sumd_sq += Domain_sums[1] [dy + y] [dx + x]; 


fsumd=sumd; fsumd_sq=sumd_sq; 














/* 


yotbest: 


sleanup: 


fpatchsize_sq = (float) (patchsize*patchsize) ; 
fmagica = (float) (sumd_sq - sumd*sumd/fpatchsize_ sq); 
for (i = 0; i < number flips; i++) { 
i = I(Range_Class[inlevel] [ry/patchsize] [rx/patchsize] [1] ] [Domai 
sumrd = 0; 
for (y = 0; y < patchsize; y++) 
for (x = 0; x < patchsize; x++) 
sumrd += Domain[y] [x] *Range[i] [y]} [x]; 
fsumrd = sumrd; 
if (fmagica != 0.) 
scale = (fsumrd - fsumd*fsumr/fpatchsize_sq)/fmagica; 
else scale = 0; 
if (scale*scale < max_scale*max scale) { 


scale = (signed char) 127. * scale / max_scale; 

scale = max_scale * scale / 127.; 

offset = (short int) (fsumr - scale*fsumd) /fpatchsize_ sq; 
mean _sq = (fsumr_sq + scale*(scale*fsumd_sq - 2*fsumrd + 2*o 


+ offset* (offset*fpatchsize sq - 2.*fsumr)) / fpatchsize 


if (mean_sq < best_mean_sq) { 
besti = i; best_mean_sq = mean_sq; bestdx = dx; bestdy 
best_scale = scale; best_offset = offset; 


if (mean_sq < mean_sq_tolerance) { 
goto gotbest; 


} /* end of conditional */ 


} 


} /* end of Domain loop */ 


for (i = 0; i < count; i++) 
GrPlot (DX [i] +300+ (patchsize>>1) ,DY[i]+(patchsize>>1) ,384); 


sprintf (rmsstr, "%8.4f",sqrt ( (double) best_mean_sq)) ; 

GrTextxXY (560,20,rmsstr,255,0); 

ifs[(0].dx = bestdx; 

ifs(0].dy = bestdy; 

ifs(0].flip = besti; 

ifs(0].scale = 127. * best_scale / max_scale; 

ifs(0].offset = (patchsize == min_patch||mean_sq < mean_sq_tolerance) ? 
ifs_table[inlevel] [ry/patchsize] [rx/patchsize] = ifs[0]; 


GrLine(rx, ry, rx, ry + patchsize, 384); 

GrLine(rx, ry ,rx + patchsize, ry, 384); 

GrLine(rx + patchsize, ry, rx + patchsize, ry + patchsize, 384); 
GrLine(rx, ry + patchsize, rx + patchsize, ry + patchsize, 384); 
} 

if ((out = fopen(outf, "ab")) == NULL) 


fprintf(stderr, "Cannot open output file.\n"); 
return 1; 


finish_time = time(finish_time) ; 








time_used = (long)difftime(finish time, start_time) 
header (0].time = time_used; 
fwrite(header, sizeof(struct header t), 1, out); 


’ 


for (ry O; ry < 32; ry++) 
for (rx = 0; rx < 32; rx++) { 
if (ifs _table(0] (ry] (rx] .offset == -500) 
for (y = 2*ry; y < 2*ry + 2; y+e+) 
for (xX = 2*rx; x < 2*rx + 2; x++) 
ifs[0] = ifs_table[1] [y) [x]; 
1lfs{0).size = 1; 
fwrite(ifs, sizeof(struct LES tb) 5 Ly outs 


ft ou 


else { 
ifs(0] = ifs_table[0] [ry] [rx]; 
ifs[0]).size = 0; 
fwrite(ifs, sizeof(struct ifs_t), 1, out); 


} 


fclose(out); 

GrSetMode (GR_default_text) ; 
* All done. Whew... */ 

return 0; 


/* end main block */ 
include "wdyusual.c" 


Se ena SE oY 








** Copyright (C) 1992 WD Young, P.O. Box 632871, Nacogdoches TX 75963-2871 


** This file is distributed under the terms listed in the document 
** "Copying.wy", available from WD Young at the address above. 

** A copy of "copying.wy" should accompany this file; if not, a copy 
** should be available from where this file was obtained. This file 
** may not be distributed without a verbatim copy of "copying.wy". 


** This file is distributed WITHOUT ANY WARRANTY; without even the implied 
** warranty Of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 


/* This program decodes .IFS files into .KRD files */ 


#include <stdio.h> 

#include <stdlib.h> 

#include <graphics.h> 

#include <math.h> 

#include <string.h> 

#define range domain 

#define max_scale 1.2 

int main(int argc, char **argv) 


unsigned char domain [256] [256], original [256] [256]; 

FILE *in, *krd, *out; 

char *inf, *krdf, psnrstr{13], rmsstr[13], timestr[13], packedstr[13], crstr 
int xsize=256, ysize=256, xhi=1, xlo=0, yhi=1, ylo=0; 

int x, y, dx, dy, rx, ry, tsx, tsy, qx, qy; 

int ii[{64] [64], ddxx[64] [64], ddyy[64] [64]; 

int transx[64] [64], transy[64) [64]; 

float ss[64] [64], oo[64] [64], z; 

int level_table[64] [64], patchsize[2] = {8, 4}, PS, PS1, number_ifses; 

int ix, iy, iddxx, iddyy, n, i, nflips=8, niterations, differences [256] [256] ; 
float rms,s, 0, psnr, tempscale, tempoffset; 
int f11[) = fy 05. -<145 0) 2 05: SL, ne £12{(] 
int £20 (1 S407 <1, Oy de Oy. = Ty. 0 1yy.. £2214 


struct trans_out { 
unsigned char dx; 





unsigned char dy; 
signed char scale; 
short int offset : 12; 
unsigned short int flip 33 
unsigned short int size 1; 
} transout [1]; 
struct header_t { /* "should" be a 12 byte header... we’ll see */ 
long time; /* 4 bytes for compression time in seconds */ 
short rms; /* 2 bytes for 100.*rms value */ 
short addl; /* 2 bytes to be added later... room for growth */ 
long add2; /* 4 bytes to be added later... room for growth */ 


} header [1]; 


if ((arge < 3)||(arge > 4)) { 
printf("\nusage: unifs iterations infile.ifs infile.krd\n\n") ; 
printf ("UNIFS Version 1.0, Copyright (C) 1992, WD Young\n"); 
printf("UNIFS comes with ABSOLUTELY NO WARRANTY\n") ; 
printf ("Please see files ‘copying.wy’ and ‘copying’ for details\n") ; 








printf("If these files are missing, \n"); 
printr("write: WD Young, P.O. Box 632871, Nacogdoches TX 75963-2871\n"); 
return 1; 


niterations = atoi(argv[l1]); 
inf = argv[2]; krdf = argv(3]; 


if ((in = fopen(inf, "rb")) == NULL) { 
fprintf(stderr, "Cannot open input file.\n"); 
oe 1; 

if ((krd = fopen(krdf, "rb")) == NULL) { 
fprintf(stderr, "Cannot open output file.\n"); 
return 1; 


GrSetMode (GR_default_graphics' ; 

for (y = 0; y < 64; yt) 
GrSetColor(y,4*ty,4*y,4*y) ; 

for (y = 64; y < 256; yt) 
GrSetColor(y,0,y/2,y); 

for (ry = 0; ry < 256; ry++) 

for (rx = 0; rx < 256; rxtt) 


original [ry] [rx] = fgetc(krd); 
GrPlot (rx+300,ry,original [ry] [rx] >>2) ; 
domain[ry] [rx] = 127; 


fclose(krd) ; 


fread(header, sizeof(struct header_t), 1, in); 
number_ifses = 0; 

for (ry O; ry < 64; ry+=2) 

for (rx QO; rx < 64; rx+=2) 


ou 


fread(transout, sizeof(struct trans_out), 1, in); 
level = transout(0].size; 
PS1 = patchsize[level] - 1; 
if (level == 0) number_ifses++; 
else number_ifses+=4; 
for (y = ry; y < ry+2; yr) 
for (x = rx; X < rx+2; x++) { 
level_tablely] [x] = level; 


if (level == 
&& (x != rx || y != ry)) fread(transout, sizeof (struct trans_out), 1, 
ddxx[y] [x] = dx = transout [0] .dx; 
ddyy {y] [x] = dy = transout [0] .dy; 
iily] [x] = i = transout [0] .flip; 
ssly] [x] = max_scale*(((float)transout [0] .scale) /127.); 
ooly] [x] = transout [0] .offset; 


transx[y] [x] 
transy [y] [x] 


2*4*x + PS1 - (f11[i]*(dx+PS1) + £12[i]* (dy+PS1)); 
2*4*y + PS1 - (£21[1]*(dx+PS1) + £22[i]* (dy+PS1) ); 


fclose (in); 

sprintf(rmsstr, "%6i",number ifses) ; 

sprintf (timestr,"%5i",header[0] .time) ; 

sprintf (packedstr, "%$4.1f", (( (float) header [0] .rms) /100.)); 
sprintf (crstr,"%5.2£",65536./(((float) number_ifses) *4.75)); 








GrTextXY(0,280, "Number of Transformations", 255, 0); 
GrTextXY(200, 280,rmsstr, 255, 0); 

GrTextXY(0,300,"38 bits/transformation gives ",255,0); 
GrTextXY (240,300, streat(crstr,":1"),255,0); 
GrTextXY(100,260,argv[2], 255, 0); 

GrTextxY (400,260,argv[3], 255, 0); 

GrTextxY(0, 360, "SECONDS ", 255, 0); 

GrTextxXY(0, 380, "PACK RMS ", 255, 0); 
GrTextXY(75,360,timestr, 255, 0); 
GrTextXY(80,380,packedstr, 255, 0); 
GrTextXY(0,460,"Copyright (C) 1992 W.D. Young", 255, 0); 
for (n = 0; n «< niterations; n++) 


/* Run through all non-overlapping NxN "R" blocks in the image */ 
for (ry = 0; ry < 64; ry++) 


GrbLine (256, 4*ry, 256, 4*ry + 4, 340); 
for (rx = 0; rx «< 64; rx++t) 


level = level_table[ry] [rx]; 
if (level == 
&& ((rx & 1) || (ry & 1))) continue; /* already covered in 8X8 */ 
PS = patchsize[level] ; 
= ss [ry] [rx]; 
o = oo [ry) [rx]; 


i = ii [ry] [rx]; 
tsx = transx [ry] [rx]; 
tsy = transy [ry] [rx]; 


iddyy = ddyy [ry] [rx]; 
iddxx = ddxx [ry] [rx]; 
[RII III III III III I ttt / 


/* Average & Transform the 256 2x2 "pixels" */ 
[ORI III III III III III III RI aa io te tote / 


for (y = 0; y < 2*PS; y+=2) 
for (x = 0; x < 2*PS; x+=2) 
dy = iddyy + y; 
dx = iddxx + x; 


z= (float) ((domain[{dy )[dx } 
+ domain[dy ] [dx+1] 
+ domain[dy+1] {dx ] 
+ domain [{dy+1] [dx+1]) >> 2); 


= (f11{[i]*dx + £12[i]*dy + tsx) >> 1; 
iy = (f21[(i] *dx + f22[i]*dy + tsy) >> 1; 

Z2 = 9*Z + O; 

if (z2 > 255.) z= 255.; else if (z < G.) z=0Q.; 
range [iy] [ix] = (unsigned char) z; 

GrPlot (ix,iy, ((int)z)>>2); 


} 
} 
rms = 0; 
for (qy = O;qy < 256; qy++) 
for a = O;qx < 256; qx++) 


differences [qy] [qx] = domain[qy] [qx] - original [qy] [qx]; 
differences [qy] [qx] *= differences [qy] [qx]; 
rms += differences [qy] [qx]; 





a ee ne ner — 


rms rms /65536.; 

rms sqrt ( (double) rms) ; 
sprintf (rmsstr,"%8.4f", rms) ; 
GrTexctXY (0,320, "RMS",255,0); 
GrTextxXY (40,320, rmsstr,255,0); 
psnr = -20*log10(rms/255.) ; 
sprintf (psnrstr,"%8.4f",psnr) ; 
GrTextXY (0,340, "PSNR",255,0); 
GrTexcxY (40,340,psnrstr,255,0); 


} 
getch(); 
GrSetMode (GR_default_text) ; 
All done. Whew... */ 
return 0; 








[kate keke keekektke keke eek kt keke eee kth kee eck keke kek keke / 


he a 
/* Usual Classification 1.0 Wy. 
js *f 


[ERK KEKE KKK EERE KEKE ee kt / 
long int usual (unsigned char image(8}][(8], int size) 


char rmsstr[13); 
int mag, max, min, class, classl, subclass, rx, ry, x, y, i, ji 
long int q[(2] [2], sumof[4], horizontal, vertical; 
unsigned char temp[size] [size] ; 
struct max_t 
int rx; 
int ry; 
} four, three, two, one; 


struct class t { 





int c; 

int m; 

} c[4322]; 
C[{4321].c = C[4123].c = C[3412] .c = C[3214].c = 
C{2341).c = C[2143]).c = C[1432].c = C[1234].c = 1; 
C[4312].c = C(4213].c = C[3421].c = C[3124].c = 

7 C[1342].c = C(1243].c = C[2431] .c = C[2134].c = 2; 

C(4132).c = C[4231].c = C[{3241].c = C[3142].c = 
C(2413).c = C[2314].c = C(1423].c = C[1324].c = 3; 
C(4321].m = 0; C[4123].m = 5; C[3412].m = 4; C[3214].m = 3; 
C(2341]) .m = 7; C[2143].m = 2; C[1432}.m = 1; C[1234].m = 6; 
C[(4312) .m = 0; C(4213].m = 5; C[{3421].m = 4; C(3124]).m = 1; 
C[1342) .m = 7; C(1243).m = 2; C[2431].m = 1; C[2134].m = 5; 
C{4132) .m = 5; C[4231).m = 0; C[3241).m = 5; C[3142].m = 2; 
C(2413) .m = 4; C({2314] .m = 3; C[(1423].m = 1; C[1324].m = 6; 
for (ry = 0; ry < size; ry +=size/2) 


0 
for (rx = 0; rx < size; rx +=size/2) { 
ql(ry/ (size/2)] [rx/(size/2)] = 0; 
for (y = ry; y < ry + size/2; y+t) 
for (x = rx; xX < rx + size/2; x++) 
q(ry/ (size/2)] [rx/ (size/2)]+=image [y] [x]; 


mag = -1; 
for (ry = 0; ry < 2; ry++) 
for (rx = 0; rx < 2; rxtt) 
if (q(ry] [rx] > mag) { 
mag = q(ry] [rx]; 
four.rx = rx; four.ry = ry; 





a{four.ry] [four.rx] = -2; 
mag = -1; 
for (ry = 0; ry < 2; ry+t+) 
for (rx = 0; rx «< 2; rx+tt+) 
if (q(ry] [rx] > mag) { 
mag = q[ry] [rx]; 








q{three.ry] [three. 
-1; 


mag 


q[two.ry] [two. rx] 
-1; 


mag 
for (ry 
for (rx 


if 


q{four.rx] [four.ry] = 
q(three.rx] (three.ry] 
q[two.rx) [two.ry] 
q{one.rx] fone. ry] 


( 


three. rx; three.ry = 


-2; 
O; ry < 2; ry++) 
O; rx < 2; rx++e) 
(q(ry] [rx] > mag) { 


mag q(ry] [rx]; 
two.rx rx; two.ry 


ry; 
-2; 


ry < 2; ry++) 
O; rx < 2; rx+t+) 
q(ry] (rx) > mag) { 
mag q(ry] [rx]; 
one .rx rx; one.ry 


4; 
= 3; 


2; 
1; 


classl = 1000*q[0] [0] + 100*q[1] [0] + 10*q[{1]) [1] + q{0] [1]; 
class = C[classi1].c; 
mapping = C[class1] .m; 
for (y = 0; y < size; y++) 
for r = 0; x < size; x++) 
if (mapping == 0) temply)] [x} =image [ +y] [ +X 
else 
if (mapping == 1) temply) [x] =image [size -1 -x] [ +y 
else 
if (mapping == 2) temp[y] [x] =image [size -1 -y] [size -1 -x 
else 
if (mapping == 3) temp[y] [x] =image [ +x] [size -1 -y 
else 
if (mapping == 4) templ[y] [x] =image [size -1 -y] [ +X 
else 
if (mapping == 5) temply] [x] =image [size -1 -x] [size -1 -y 
else 
if (mapping == 6) temp[y] [x] =image [ +y] (size -1 -x 
ae temp [y] [x] =image [ +x] [ +y 


if (mapping != 0) 


finish: 


sumof[0] += 
sumof[2) += 


for (y 0; y < gize; y+t+) 
for (x = 0; x < size; x++) 
image [y] [x] temp [y] [x]; 


= 


NW 


< 
< 


sumof [1] sumof [2] 


= 


= sgumof [3] 


0; 


j*size/2; ry < j*size/2 + size/4; ry ++) 
i*tsize/2; rx < i*tsize/2 + size/2; rx ++) { 
image (rx] [ry]; 

image [rx] [ry+size/4] ; 











} 
( 
for (rx = i*size/2; rx < itsize/2 + size/4; rx ++) { 


sumof{1] += image[rx] [ry]; 
sumof [3] += image[rx+size/4] [ry]; 


for (ry j*size/2; ry < j*size/2 + size/2; ry ++) 


horizontal = labs(sumof[0] - sumof[2]); 
vertical = labs(sumof{1] - sumof{[3]); 
q(ilf{j] = (horizontal >= vertical); 


subclass = 10000*class + 1000*q[0] [0] + 100*q[1] [0] + 10*q{0] [1] 


return subclass; 











APPENDIX C 


TABLE C.1: LENA LOSSLESS COMPRESSION RESULTS. 


Method Compress | Compress | Decompress Total 
Ratio Time Time Time 
12.10 


Adapt Huff 
10.66] 2.96] 29.62 


TABLE C.2: AERIAL LOSSLESS COMPRESSION RESULTS. 


Method Compress | Compress | Decompress Total 
Ratio Time Time Time 
Huf fman 1.13 11.48 


Adapt _Huff 17.09 
10.38 1e.52| 28.90 


TABLE C.3: SIGN LOSSLESS COMPRESSION RESULTS. 


Compress | Compress | Decompress Total 
Ratio Time Time Time 
fHuftman | 7.37| nae] ase | 04 | 






























721 














TABLE C.4(a): JPEG COMPRESSION RESULTS FOR LENA. 


Pie te fe le le 
FEEREEEEEEEE ERE 


eee ee) eee 


6.54 


| s.65| 12.88 
13.07 
13.24 

















TABLE C.4(b): JPEG COMPRESSION RESULTS FOR AERIAL. 



















pas | 9.64] 3.29] 3.30] 6.49 | 23.08, 
fay | s.96| 3.24 3.30 
ee es ee ee ee ee 
p21 | asoof 3.24] 3.23] 6.37] 24.6 | 
3 ‘ : 
4 . : 














23 | asas| 3.29] 3.30] 6.49] 2.94 
11.72 
25.36 
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TABLE C.4(c): JPEG COMPRESSION RESULTS FOR SIGN. 













22.04 
22.44 





74 








TABLE C.5(a): FRACTAL COMPRESSION RESULTS FOR LENA. 


Decomp 
Time 
(sec) (sec) 
4.57 
7.04 
9.28 
| 27.97] 64 | 3.40] 67 | 22.07 





TABLE C.5(b): FRACTAL COMPRESSION RESULTS FOR AERIAL. 


Error Optim Comp Decomp 
Cut Level Ratio i Time 
(sec) 


ae oo ee 
aes ae ee eee ee ee ee 


10.17 
s__| 16.09} 105 | 4.00] 109 | 22.62 | 
eee eee | so | 24.74 | 
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TABLE C.5(c): FRACTAL COMPRESSION RESULTS FOR SIGN. 







Decomp 
eas 
(sec) 


A A PE TT 
2} sf ars} 2s3_| 3.24 | ass | 3.07 
Py fs | ss.s6f 222 | a.20[ 225 [asa 
p20 fs | zt { as7 | 3.ns{ x60 | 26.20] 
ps | gap a} aa |g a5 | a | 27.92 
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